オンプレのSQL ServerからAWSへレプリケーションをする – 1.基礎知識 –

こんにちは、せーのです。 ディザスタリカバリ(DR)が叫ばれている昨今、手元にあるDBサーバーのデータをクラウドに退避させておきたい、また負荷分散のために同じデータだけど部門ごとで参照するDBを分けたい、というようなご要望は多いです。 ではAWS上にSQL Serverを立てて、元々あるSQL Serverのデータを定期的に、またリアルタイムにレプリケーションさせることは可能なのでしょうか？今回から数回にわけてオンプレにあるSQL ServerをAWS上にレプリケーションさせる方法とポイントを書いていきます。 初回となる今回はまず基礎知識としてレプリケーションではどういう処理が行われるのか、SQL Serverで使用できるレプリケーションの種類についてお話したいと思います。

レプリケーションの仕組み

まず最初に、レプリケーションの仕組みについてお話します。 全体図はこのようになります。

SQL Serverのレプリケーションに出てくる登場人物は３人です。名称は本や雑誌などの流通がモデルになっています。

• パブリッシャー(出版社) - アーティクル(出版物、この場合レプリケーション対象となるDBやテーブル)をパブリケーション（出版）する大元。
• ディストリビューター(流通業者) - アーティクルを必要に応じて色々なところに配布する。
• サブスクライバー(購読者) - ディストリビューターから定期的にアーティクルをサブスクリプション(購読)する。

なんとなくイメージがつかめたでしょうか。出版する人がいて、それを運ぶ人がいて、最後にそれを読む人がいる。レプリケーションの基本構造はこのようになっています。

SQL Serverのレプリケーションの種類

SQL Serverのレプリケーションは３種類の方法に分かれています。一つ一つ見て行きましょう。

スナップショットレプリケーション

一番わかりやすい方法ですね。その時点でのDBのスナップショット(写真）を取り、そのまま運んで、サブスクライバーにどーん、と上書きしてしまう方法です。 メリットとしては、DBが細かい事を考えなくて済むので処理時間が速いです。次に説明するトランザクションレプリケーションと比べるとデータの更新が多い場合、また随時変更するのではなく、一時期に一斉に値が変わる時にはこの方法が適しています。例えば商品テーブルを持っていて、その原価、売価が消費税増税によりあるタイミングで一斉に変わる、夏のボーナスで一時的に一気に下げる、などという場合はスナップショットを取ってまるっとレプリケートした方が良いですね。 ただし、全体のデータ量が多ければ当然スナップショットも巨大なものとなり、リソースを食うことになります。また頻繁にデータを追加、更新する場合、毎回スナップショットを取って上書きするのは逆にオーバーヘッドがかかります。

トランザクションレプリケーション

データベースはデータを追加、更新、削除する際に必ずどのデータにどういう値が加わった、更新された、等の履歴が記録されています。これをトランザクションログと言います。トランザクションレプリケーションはこのトランザクションログをサブスクライバーに運んで、前回からの更新履歴を踏襲させることで同期させよう、という方法です。 ちなみにトランザクションレプリケーションとこの後ご紹介するマージレプリケーションは初回のレプリケーションではスナップショットを配布します。2回目以降に前回からの増分、更新分をトランザクションログの形で配信するんですね。 この方法のメリットとしては、一つ一つのトランザクションログは小さなものであるため、追加、更新されるたびにログをレプリケートしていくと、よりリアルタイムなレプリケーションが可能になることです。 また変更履歴を追うこともできます。通常同じテーブルのカラムデータが3回変更されるとユーザーは最後の変更結果しかわからないものですが、トランザクションログを使うことによって、どういう値に変化していったのか、という履歴を追いながら処理を追加することができます。 トランザクションログ自体はOracleなどのREDOログとも共通する部分が多く、SQL ServerのトランザクションログをOracleにサブスクリプション、なんてこともできたりします。 一方トランザクションレプリケーションの欠点としてはデータベースモードを変える必要がある、というところです。 トランザクションログをサブスクライバーに適用させるためには「Restoreモード」という専用モードにする必要があり、このモードになると一般的なデータの読み書きはできません。ですので、一旦Restoreモードにして、トランザクションログを適用させて、また一般モードに戻す、という作業が必要になります。

マージレプリケーション

最後はマージレプリケーションです。この方法は、サブスクライバー側でもデータの変更をする場合、パブリッシャー側とサブスクライバー側のデータ更新を合わせてマージして交換しよう、という方法です。 マージレプリケーションはサブスクライバー側のネットワークがオンラインになる時をトリガに行われます。つまり、gitやHTML5のオフラインアプリケーションのような仕組み、と捉えて貰えればわかりやすいかと思います。 「gitのような仕組み」とお話したところでピン、ときた方もいるかと思いますが、この方法のデメリットは競合（コンフリクト）が発生する可能性がある、ということです。パブリッシャーとサブスクライバーで同じデータを更新した場合、どちらの値を優先するのか、という判断を事前に設定しておく必要があります。

次回はトランザクションレプリケーションの実装編

さて、レプリケーションの処理と種類について、だいぶイメージがつかめたのではないでしょうか。 今回はここまで。次回は今日ご紹介した3種類のレプリケーションのうち「トランザクションレプリケーション」と取り上げ、実際にAWS上に実装していきたいと思います。それでは次回。